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(54) Title: METHOD FOR CONTROLLING PROGRAM EXECUTION INTEGRITY BY VERIFYING EXECUTION TRACE 
PRINTS 

(54) Titre : PROCEDE DE CONTROLE DINTEGRITE DEXECUTION DE PROGRAMMES PAR VERIFICATION DEM- 
PREINTES DE TRACES DEXECUTION 



(57) Abstract: The inventive method for controlling a program execution integrity by verifying execution trace prints consists in 
tf^ updating the representative print of an execution path and/or data applied for a program execution, comparing the actual print value 
(dynamically calculated to an expected value (statistically fixed, equal to a value of the print if the program execution is not disturbed) 
at a determined program spots and in carrying out a particular processing by the program when the actual print differs from the 
expected value. 

(57) Abrege : Procede de controle d'integrite d'execution de programmes par verification d'empreintes de traces d'execution mettant 
en oeuvre: - la mise a jour d'une empreinte representative du chemin d'execution et/ou des donnees manipulees lors de I'execution 
du programme, - la comparaison de la valeur courante de I'empreinte (calculee dynamiquement) a une valeur attendue (fixee sta- 
tiquement, egale la valeur que doit avoir I'empreinte si I'execution du programme n'est pas perturbee) en des points determines du 
programme, - la realisation d'un traitement particulier effectue par le programme au cas ou I'empreinte courante differe de la valeur 
attendue. 
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PROCEDE DE CONTROLE D'INTEGRITE D^EXECUTION DE 
5 PROGRAMMES PAR VERIFICATION D^EMPREINTES DE TRACES 
D'EXECUTION, 



10 La pr6sente invention a pour objet un procede de controle d'integrite 
d' execution de programmes par verification d'empreintes de traces 
d' execution. 

Elle s'applique notamment au controle d'integrite d' execution de programmes, 
15 ladite execution de programmes mettant a jour une empreinte representative 
du chemin d' execution et/ou des donnees manipulees, sachant qu'en des 
points determines du programme, la valeur courante de T empreinte est 
comparee a une valeur attendue. 

20 Certains petits systemes embarques, comme par exemple les cartes a puce, 
sont con9us pour proteger les donnees et programmes qu'ils contiennent. En 
particulier, le support materiel de ces systemes rend tres difficile T observation 
et la modification des donnees stockees, y compris lors de T execution des 
programmes. 

25 

La protection n'est toutefois pas totale. Ces systemes peuvent etre exposes a 
des actions malveillantes (aussi appelees « attaques ») qui visent a alterer le 
bon fonctionnement du systeme et des programmes, ou a devoiler des 
informations confidentielles. Des attaques physiques (aussi dites materielles) 
30 sont par exemple des perturbations de T alimentation electrique, des 
bombardements par des rayonnements, la destruction de portes logiques, etc. 



wo 2005/073859 PCT/FR2004/003273 

2 

De telles attaques peuvent conduire a des dysfonctiomiements du programme 
execute sur la carte : les instructions et les donnees lues depuis la memoire 
peuvent etre incorrectes, et le processeur pent executer incorrectement 
certaines instructions. De telles perturbations peuvent rendre invalide du code 
5 qui verifie des conditions de securite avant d'operer certaines actions 
sensibles. 



Soit Texemple (simplifie) du code suivant, ecrit en langage C : 
if (! condition 1()) goto error; 
10 if (! condition2()) goto error; 

do_sensitive_action() ; 



L' action sensible « do_sensitive_action() » n'est normalement executee que si 
les deux conditions « conditionl() » et « condition2() » sont satisfaites. 
15 Neanmoins, des perturbations physiques peuvent amener le processeur k sauter 
directement par-dessus le code des deux « if » ou a lire depuis la memoire une 
s6rie d' instructions diff6rentes du code des deux «if». Dans ce cas, le 
processeur peut executer « do_sensitive_action() » meme si les tests 
« conditionlQ » et « condition2() » ne sont pas satisfaits. 

20 

Une technique connue pour « durcir » un programme contre ce genre 
d' attaques consiste a introduire de la redondance entre le flot de controle du 
programme et les valeurs de certaines variables auxiliaires. En d'autres 
termes, on utilise des variables auxiliaires pour garder trace du fait que 
25 Tex^cution est bien passee par toutes les verifications de conditions de 
securite. Dans le cas de I'exemple ci-dessus, on pourrait ecrire : 
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trace = 0; 

if (condition IQ) trace |= 1; else goto error; 
if (condition2()) trace |= 2; else goto error; 
if (trace == 3) do_sensitive_action(); 

5 

Ainsi, si les deux premiers « if » ne sont pas executes correctement, il y a de 
bonnes chances que la variable « trace » ne soit pas 6gale a 3 a la fin, et que 
Taction « do_sensitive_action() » ne soit done pas executee. 



10 Meme dans ce cas, une perturbation pourrait faire en sorte que le test « trace 
= 3 » soit toujours vrai ou soit lui aussi ignore. De maniere generale, pour la 
pertinence de I'invention presentee ici, on fait Thypothdse que les 
perturbations causees par des attaques physiques sont relativement grossieres : 
elles peuvent inactiver T execution d'une partie du programme ou changer le 

15 contenu apparent d'une partie de la memoire, mais I'etendue de cette partie 
n'est pas controlable finement par Tattaquant. 



Cette approche pent se generaliser de la maniere suivante. Le programme tient 
k jour une valeur representative des points de controle importants par lesquels 

20 passe son execution. Cette valeur peut etre ime empreinte (un « hash »), par 
exemple une somme de controle (« checksum »), calculee sur des entiers qui 
caracterisent ces points de controle importants. Avant d'executer une 
operation sensible, cette valeur mise a jour en cours d' execution peut etre 
comparee a sa valeur normale (attendue), precalculee manuellement par le 

25 programmeur a partir de la structure de controle du programme. Par exemple : 
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trace = 42; 

for (i = 0; i < 4; i++) { 

if (provided_pin[i] != actualjpm[i]) goto error; 
trace = h(trace5 i); 

5 } 

if (trace = 2346) do_sensitive_action(); 

II faut cependant noter que ce n'est pas ainsi qu'une verification de code PIN 
est habituellement codee ; il s'agit juste ici d'xin exemple illustratif de Tusage 
10 du calcul d' empreinte. 

L'operateur de hachage utilise ici est la congruence lineaire « h(t,x) = ((33 * t) 
mod (2'^16)) xor x » ou : 

• « a * b » represente le produit de « a » par « b », 

15 • « a mod b » represente le reste de la division de « a » par « b » (c'est-a-dire 
le modulo), 

• « a b » represente T elevation de « a » a la puissance « b », 

• « a xor b » est T operation « ou logique exclusif » sur les bits representant 
« a » et « b ». 

20 

La valeur 2346 n'est autre que « h(h(h(h(42, 0), 1), 2), 3) », c'est-a-dire 
r empreinte de 1' execution normale de la boucle (4 tours pour « i » variant de 0 
a 3). Si la boucle n'est pas executee ou si elle se termine anormalement avant 
d' avoir fait 4 tours, la valeur de la variable « trace » avant Tappel de 
25 « do sensitive_action() » sera tr^s probablement diff6rente de 2346. 
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On peut voir cet operateur de hachage « h » comme un operateur qui permet 
de calculer incrementalement une fonction de hachage « H » qui opere sur des 
sequences d'entiers qui caracterisent lesdits points de controle importants, 
Cette fonction de hachage sur ies sequences d' observations est definie par : 

5 « H(To, ib 12, .... in) = H' • -hCKTo. ii). 12). • in) »• 

Pour pouvoir etre utilisee dans des petits systemes embarques disposants de 
faibles capacites de calcul, T operateur de hachage «h» doit etre rapide a 
calculer. De plus, la fonction de hachage «H» r6sultante doit aussi etre 
10 resistante aux pre-images : la probabilite pour que Tempreinte 
« H(To, iu in) » d'une sequence aleatoire « To, iu in » soit egale a une 
valeur donn6e doit dtre faible (de Tordre de 2"^ ou B est le nombre de bits 
pour coder la valeur de rempreinte.) 

15 Dans certains cas decrits ci-dessous, il pourra aussi etre utile de disposer d'un 
operateur de hachage « h » qui soit inversible en son premier argument : pour 
toutes valeurs « t' » et « x », il existe « t » tel que « t' = h(t5 x) ». 

On peut par exemple utiliser pour « h » ime congruence lin^aire, comme c'est 
20 le cas dans Texemple donne ci-dessus. Cette congruence lineaire a de plus la 
propriete d'inversibilite. Plus generalement, on peut utiliser n'importe quelle 
fonction qui combine les operations suivantes : addition, soustraction, ou 
logique exclusif (xor) avec une constante ou avec « x » ; rotation d'un nombre 
constant de bits ; multiplication par ime constante impaire. 

25 

On peut utiliser egalement une fonction de controle de redondance cyclique 
(CRC), comme par exemple CRC-16 ; une telle fonction peut etre calculee de 
maniere efficace a Taide de tables precalculees. 
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En revanche, meme si une somme de controle (checksum, definie comme la 
somme des entiers passes en argument) a bien les bonnes proprietes de rapidite 
de calcul, de resistance aux pre-images, et d'inversibilite, elle est peu 
satisfaisante car la fonction de hachage obtenue est insensible a Tordre des 
5 arguments. 



A r autre extremite du spectre se trouvent des fonctions de hachage 
cryptographiques (digests, comme SHA-1, MD-5, etc.) qui sont tres sures mais 
aussi coftteuses k calculer. 

10 

La prise d'empreinte pent se d6crire a Taide de deux operations principales 
d' affectation et de mise a jour d'empreinte : « setTrace(T) » fixe la valeur 
initiale de Tempreinte a «T» (typiquement, une valeur quelconque), et 
« addTrace(N) » ajoute a la trace un entier «N» caracteristique d'une 
15 observation de T execution du programme. Dans Texemple ci-dessus, 
« setTrace(T) » correspond a T affectation « trace = T; » et « addTrace(N) » 
correspond a la mise a jour de Tempreinte par « trace = h(trace, N) ». 



La valeur « N » foumie lors d'une operation « addTrace(N) » pent elle-mdme 
20 etre le resultat d'une fonction de hachage. Plus rentier « N » est representatif 
de r execution locale du programme, c'est-a-dire plus « N » varie en presence 
d'une perturbation possible de 1' execution, meilleur est le pouvoir de detection 
d'une attaque. 



25 La verification d'empreinte peut se decrire a I'aide d'une unique operation : 
« checkTrace(T) » verifie que la valeur courante de I'empreinte est bien « T ». 
Dans le cas contraire, c'est une indication que le programme a subi une 
attaque. En toute rigueur, des systemes comme des cartes a puce s'usent et une 
difference d'empreinte pourrait aussi 6tre le signe d'lme defaillance materielle. 
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Dans tous les cas, le programme ne peut plus rendre le service pour lequel il 
est congu. Dans des systemes critiques, les mesures prises en cette 
circonstance consistent typiquement a securiser certaines donnees du 
5 programme et k interrompre, definitivement ou non, son execution. Lorsque 
c'est materiellement possible, un signal sonore ou visuel peut en outre avertir 
Tutilisateur du dysfonctionnement, 

Au vu de Texemple ci-dessus, il est manifeste que la mise en oeuvre de cette 
10 technique demande beaucoup d' efforts de la part du programmeur, d'une part 
pour inserer les etapes de calcul de Tempreinte, de Tautre pour calculer les 
valeurs attendues de Tempreinte aux points ou elle devra etre verifiee. 

Compte tenu des problemes precedemment evoques, T invention a plus 
15 particulierement pour but la generalisation de cette technique et son 
automatisation. 

A cet effet, elle propose im procede de controle d'integrite d' execution de 
programmes par verification d'empreintes de traces d' execution mettant en 
20 oeuvre : 

- la mise a jour d'lme empreinte representative du chemin d'execution 
et/ou des donnees manipulees lors de T execution du programme, 

- la comparaison de ladite empreinte (valeur courante, calculee 
dynamiquement) a une valeur attendue (fixee statiquement, egale la 

25 valeur que doit avoir Fempreinte si Texecution du programme n'est 

pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier dans le cas ou T empreinte 
courante differe de la valeur attendue. 



wo 2005/073859 



8 



PCT/FR2004/003273 



Ce procede pourra prendre en compte : 

- que ladite empreinte ne porte que sur des fragments de code 
critiques du programme, 

5 - que les valeurs attendues de I'empreinte en des points donn6s du 

programme sont determinees par une analyse statique de programme 
qui modifie eventuellement le code de programme pour rendre les 
valeurs d' empreinte previsibles. 

10 Ce procede et ses perfectionnements sont decrits plus en detail ci-apres k tilre 
d'exemples non limitatifs. 

L' analyse de programme pour la determination des valeurs d' empreinte 
attendues pent se decomposer en plusieurs etapes. On considere tout d'abord 
15 le cas d'une routine (methode, sous-programme, etc.) du programme. 

Dans le cas ou toutes les instructions separant le debut de la routine d'un point 
de controle d' empreinte sont lineaires, c'est-a-dire ne contiennent pas de 
branchements, la valeur attendue de T empreinte est simplement 
20 « h(. . .ti(h(To, ii), ia). . in) » ou « To » est la valeur initiale de I'empreinte et oil 
«ii, ...5in» sont les entiers representatifs de T execution au divers points 
d' observation sur le chemin d' execution. 

Plus generalement, 6tant donne une decomposition d'une routine sous forme 
d'un graphe de blocs de base (basic blocks), si Ton connait statiquement la 
25 valeur de I'empreinte au debut d'un bloc de base, on connait de la meme 
maniere sa valeur en tout point du bloc. 
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Lorsque plusieurs chemins d' execution differents menent en irn meme point de 
programme, il n'est pas possible de predire « la » valeur d'empreinte attendue 
en ce point de programme puisqu'il y en a en fait plusieurs. Dans ce cas, on 
« egalise » les valeurs de Tempreinte aux points de jointure dans le flot de 

5 controle : sur chaque branche qui mdne au point de jointure (sauf 
eventuellement une des branches), on ajoute a Tempreinte courante une valeur 
constante telle que Tempreinte resultante est la meme pour chaque branche, 
une fois atteint le point de jointure. Cette addition peut se faire explicitement 
dans le code, par exemple par operation directe sur la valeur de Tempreinte ou 

10 par appel a une routine dediee. Soit par exemple le programme suivant : 

if (cond) { 

addTrace(l); 



addTrace(2); 



15 } else { 



addTrace(3); 



addTrace(4); 



} 



20 Si Tempreinte a la valeur « To » avant le « if », elle aura respectivement les 
valeurs « h(h(To, 1), 2) » et « h(h(To, 3), 4) » a la fin de chacune des deux 
branches de ce « if ». Pour etablir un point de controle d'empreinte apres ce 
« if », on peut 6galiser les branches de la manidre suivante : 
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if (cond) { 



addTrace(l); 



addTrace(2); 



5 



} else { 



addTrace(3); 



addTrace(4); 



adjustTrace(X); 



10 



} 



checkTrace(Y); 
avec les definitions suivantes : 

• « adjustTrace(N) » ajoute rentier «N» a la valeur courante de 
Tempreinte, 

15 • « X » est egal a « h(h(To, 1), 2) - h(h(To, 3), 4) », 

• « Y » est egal a « li(h(To, 1), 2) ». 

Ainsi, quel que soit le chemin d' execution pris, I'empreinte vaudra toujours 
« Y » apres le « if ». Le fait d'additionner la valeur « X » a la valeur courante 
20 de Tempreinte rend cette empreinte pr6visible tout en pr^servant le fait qu'elle 
est difficile a falsifier. L'ajustement aurait pu etre pratique de maniere 
symetrique sur la premiere branche du « if » plutot que sur la seconde. 

Ce schema s' applique aussi au cas des boucles dont le nombre d' iterations est 
25 ind6termin6 : h chaque tour de boucle, T empreinte est ajustee pour revenir a la 
meme valeur initiale. 
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L'operation d'ajustement d'empreinte « adjustTrace » s'ajoute aux operations 
de mise a jour d'empreinte («addTrace») et d' affectation d'empreinte 
(« setTrace ») pour former Tensemble des operations de « prise d'empreinte ». 

5 

L' operation d'ajustement d'empreinte « adjustTrace(N) » n'a pas a etre 
necessairement une operation basee sur une operation d' addition du genre 
« trace = trace + N; ». EUe pent etre plus gen6ralement definie comme 
« trace = adjust(trace, N); » ou « adjust(T, N) » est une fonction inversible en 
10 son premier argument: pour toute empreinte d'origine «T» et toute 
empreinte cible « T' », il suffit de savoir determiner « N == deltaCT, T') » tel 
que « adjustCT, N) = T' ». 

On retrouve ainsi le cas de T addition : « adjustCT, N) = T + N » et 
15 « delta(T, T') == T' - T ». Mais on pent aussi par exemple utiliser le «ou 
logique exclusif » : « adjust(T, N) = T xor N » et « delta(T, T') = T xor T' ». 

L'ajustement d'empreinte « adjustTrace(delta(T, T')); » envoie I'empreinte 
« T » sur I'empreinte « T' » en preservant la difficulte de falsification. 

20 Les gestionnaires d' exceptions (exception handlers) d'lm programme rendent 
difficile la determination statique des valeurs de I'empreinte. En effet, 
r execution peut se brancher au debut du code du gestionnaire a partir de 
n'importe quelle instruction couverte par ce gestionnaire. La valeur de 
I'empreinte au debut du code du gestionnaire n'est done pas pr6visible 

25 statiquement. La mise en place d'ajustements d'empreinte comme decrits ci- 
dessus pour toutes les instructions couvertes par un gestionnaire d' exception 
permet en principe d' assurer une valeur d'empreinte connue au debut du 
gestionnaire. Cependant, comme le nombre d'ajustements necessaires est 
grand, cela peut etre coiiteux en taille de code, en particulier si les ajustements 
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sont codes explicitement par des appels de routine du type « adjustTrace(N) »• 
En outre, les ajustements auraient comme effet secondaire de rendre 
Tempreinte constante sur tout Tintervalle du code convert par un gestionnaire 
d' exception: L'empreinte serait done alors inefficace pour detecter les 
5 perturbations d' execution. 

Une solution a ce probleme est de forcer Tempreinte a une valeur connue 
statiquement lorsque T execution entre dans un gestionnaire d' exceptions. Cela 
pent etre fait par Tinterprete de la machine virtuelle, lorsqu'il traite le 
10 rattrapage d'une exception. Une autre possibilite est d'inserer un appel a une 
routine « setTrace(T) » au debut de chaque gestionnaire d' exceptions, ou « T » 
est une valeur choisie arbitrairement ; cette routine positionne la variable 
« trace » a la valeur de son argument. 

15 Avec cette solution, la propriete de controle d'integrite d' execution est 
localement perdue enire le fragment d' execution qui precede le branchement 
et celui qui le suit. Mais elle reste globalement preservee sur T ensemble de 
r execution du programme. 

20 Cette methode pent plus generalement s'appliquer a tous les points de forte 
convergence du flot de contrdle de la routine. 

Les subroutines, dans des langages comme ceux de la machine virtuelle 
«Java» (JVM) ou «Java Card» (JCVM) (marques depos6es par Sun 
25 Mycrosystems), posent par exemple un probleme similaire. Elles peuvent en 
effet etre appelees depuis plusieurs points du code, avec des valeurs 
differentes pour Tempreinte. On pent les traiter de la m8me maniere que les 
gestionnaires d'exception, en for9ant la valeur de Tempreinte lorsqu'on entre 
dans une subroutine. Les points d' appels de subroutines etant bien delimites 
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(par exemple, instructions « jsr » de la JVM et de la JCVM) et generalement 
assez peu nombreux, on pent aussi les traiter comme des branchements 
normaux, avec insertion d'appels a « adjustTrace » avant les appels de 
subroutines pour garantir une meme valeur de Tempreinte en tous les points 
5 d'appel d'une meme subroutine. 

Par ailleurs, le calcul d'empreinte et son contrSle peuvent toujours 6tre limit^s 
a des fragments de code critiques du programme. Cela permet de reduire 
Taccroissement en taille du code pour introduire la redondance que 
10 representent les operations sur les empreintes. Cela reduit egalement le 
ralentissement du aux calculs supplementaires du programme. 

Les operations sur les empreintes ne modifient pas le comportement du 
programme (en T absence de perturbation). Les operations de mise a jour 

15 d'empreinte (du type «addTrace») et d'ajustement d'empreinte (de type 
« adjustTrace ») se placent conceptuellement sur les arcs du graphe de flot de 
controle qui relie entre eux les points d' execution du programme. De cette 
maniere, la mise a jour d'empreinte et Tajustement peuvent dependre non 
seulement des points de programme parcourus en cours d' execution mais aussi 

20 des branches specifiques suivies, y compris dans le cas ou plusieurs branches 
relient deux memes points. En pratique, dans le cas ou les operations de mise a 
jour et d'ajustement d'empreinte sont inserees effectivement dans le code 
executable du programme, elles sont disposees de maniere a dtre ex6cut6es en 
sequence entre les deux points de programme de Tare sur lesquelles elles sont 

25 plac6es. Cette insertion pent necessiter des modifications locales mineures du 
programme, comme Tajout de branchements supplementaires. 

En revanche, les operations d' affectation (de type « setTrace ») et de controle 
d'empreinte (de type « checkTrace ») se placent conceptuellement sur les 
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points de programme et non sur les arcs entre ces points. La valeur de 
Tempreinte est en effet une propriete des points de programmes : quels que 
soient les chemins d' execution menant a un point de programme donne, la 
valeur courante de I'empreinte (calculee dynamiquement) doit etre egale a une 
5 valeur fixe attendue (connue statiquement) ; et cette valeur attendue pent 6tre 
forcee par une operation d' affectation d'empreinte. 



La valeur de Tempreinte en chaque point d' execution d'une routine de 
programme ainsi que les ajustements a inserer pour rendre previsible la valeur 
10 de Tempreinte peuvent etre determines automatiquement par une analyse 
statique de programme qui modifie eventuellement le code du programme 
pour rendre les empreintes previsibles et pour les contr61er. 



On se donne pour cela une routine du programme et des informations 
15 concemant la mise a jour d'empreinte (points de programme et nature des 
observations de T execution en ce point de programme), T affectation 
d'empreinte (points de programme ou Tempreinte doit etre forcee a certaines 
valeurs) et eventuellement le controle d'empreinte (points de programme ou 
I'empreinte doit etre controlee). 

20 

Les informations de mise a jour, d' affectation et de controle d'empreinte 
peuvent par exemple Stre donn6es par des insertions explicites de directives 
(commentaires, pragmas, code effectivement execute, etc.) dans le code du 
programme. De telles directives sont considerees de maniere neutre du point 
25 de vue du flot de contrdle du programme : les directives de mise a jour 
d'empreinte de type «addTrace» se placent entre deux points d' execution 
effectifs (hors directives) du programme, et ainsi sur les arcs qui relient 
conceptuellement entre eux les points d' execution du programme ; les 
directives d' affectation («setTrace») et de controle d'empreinte 
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(« checkTrace ») portent sur le point d' execution qui suit. II en va de meme 
pour les directives 6ventuellement inserees par la transformation de 
programme : les directives d'ajustement de type « adjustTrace » sont 
egalement neutres et se placent sur les arcs (pour corriger la valeur d'une 
5 empreinte avant d'atteindre un point de programme), c'est-^-dire entre deux 
points d' execution. 



Les directives d' affectation d' empreinte peuvent avoir ete placees par une 
transformation de programme pr^alable. Cette transformation pent par 
10 exemple systematiquement placer une directive de type « setTrace » en tous 
les points de programme ou conflue un nombre de branches d' execution 
superieur k un seuil donne. De telles directives peuvent Egalement etre placees 
systematiquement a tous les points d' entree des subroutines et/ou des 
gestionnaires d' exception. 

15 

De meme, les valeurs manipulees par les directives de mise a jour d' empreinte 
peuvent aussi avoir ete d^terminees par une transformation de programme 
prealable. En effet, les valeurs utilisees pour cette mise a jour (argument de 
« addXrace ») sont en general des constantes arbitraires. Une valeur 

20 quelconque (par exemple aleatoire) peut done §tre automatiquement attribuee 
a chaque occurrence d'une telle directive. Dans certains cas, on peut aussi 
vouloir exploiter des invariants du programme. On procede alors a une analyse 
statique du programme afin de determiner des invariants en certains points de 
programme, par exemple le fait que la somme de deux variables est constante 

25 le fait qu'une variable est inferieure a un certain seuil, le fait que le nombre de 
tours de boucle est connu, etc. Ensuite, au lieu de mettre ^ jour T empreinte en 
fonction de constantes, on emploie des expressions qui, bien qu'elles portent 
sur des donn^es dynamiques du programme, doivent avoir une valeur 
constante. 

30 
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Le precede de determination automatique des valeurs d'empreinte attendues 
est ensuite defini par la sequence operatoire suivante. 

• Initialisation de T ensemble des points de programme k explorer au 
singleton constitue de la premiere instruction de la routine. 

5 • Memorisation au point d' entree de la routine d'une valeur d'empreinte 
egale a la valeur initiale donnee de Tempreinte, 

• Tant que ledit ensemble des points de programme a explorer n'est pas 
vide : 

- Extraction d'un point de programme (le point d'origine) dudit ensemble 
10 des points de programme a explorer. 

- Pour chacun des points de programme resultants possibles apres 
execution de T instruction (les points cibles) : 

Si le point cible comporte une affectation d'empreinte et si ce point 
cible n'a pas encore ete explore, memorisation au point cible de la 
1 5 valeur d' empreinte definie par V affectation. 

Si le point cible ne comporte pas d' affectation d' empreinte et si ce 
point cible a deja ete explore, insertion entre P instruction au point 
d'origine et T instruction au point cible d'un ajustement d' empreinte 
qui envoie la valeur de T empreinte au point d'origine sur la valeur 
20 de r empreinte memorisee au point cible. 

Si le point cible ne comporte pas d' affectation d' empreinte et si ce 
point cible n'a pas encore ete explore, memorisation au point cible 
de la valeur de T empreinte au point d'origine, 6ventuellement 
modifiee par une mise a jour d' empreinte s'il y en a une entre le 
25 point d'origine et le point cible. 

Si le point cible n'a pas encore ete explore, ajout dudit point cible dans 
ledit ensemble des points de programme a explorer. 
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Certains langages ne permettent pas de manipuler facilement des directives 
neutres du type des directives de prise et de contr61e d'empreinte decrites ci- 
dessus. On peut employer dans ce cas ime technique qui consiste a 
instrumenter le code du programme avec des instructions reelles. 



20 



Par exemple, on peut inserer dans le code du programme des appels de routine 
explicites, aussi bien pour la mise a jour d'empreinte et T affectation 
d'empreinte que pour le controle d'empreinte. Par exemple, on peut ecrire en 
« Java »: 



10 { 



if (cond) { 



a[i+j]=b[i]; 
addTraceO; 



15 } 



checkTraceO; 



} 



catch (Exception e) { 
setTraceO; 



Ce fragment de programme peut etre transforme une premiere fois pour 
r attribution de valeurs d'empreinte arbitraires pour les operations de mise a 
jour et d' affectation : 
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if (cond) { 

a[i+j] = b[i]; 
addTrace(28935); 

} 

checkTraceQ; 

} 

catch (Exception e) { 
setTrace(9056); 

• • • 

} 

Puis, le programme peut etre transforme une seconde fois selon le precede 
d6crit ci-dessus pour determiner les valeurs d'empreinte aux points de controle 
15 et pour inserer les ajustements necessaires. Les valeurs attribuees par cette 
transformation dependent de Toperateur de hachage utilise. Le fragment de 
programme donne en exemple ci-dessus pourra etre transform^ ainsi : 



5 



10 
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{ 



} 



if (cond) { 



a[i+j] = b[i]; 
addTrace(28935); 
adjustTrace( 16220); 



} 



checkTrace(13991); 



10 catch (Exception e) { 

setTrace(9056); 



> 



15 Si Ton veut pouvoir compiler et executer le programme avant transformations, 
par exemple pour le mettre au point, il peut falloir adapter le programme 
source. En effet, si la librairie de prise et de controle d'empreinte ne comporte 
que des routines qui prennent en argument im entier, il est illegal d'ecrire 
« checkTraceO ». Dans ce cas, on peut adopter la convention suivante : la 

20 valeur « 0 » (par exemple) denote une valeur encore indeterminee. On ecrit 
alors « checkTrace(O) » dans le code source initial. Apres transformation, 
Tappel de routine deviendra par exemple « checkTrace(13991) ». 



Cette technique est compatible avec la compilation du programme : les 
25 transformations de programme peuvent se faire aussi bien sur le code source 
que sur le code objet. Par exemple, en « Java Card », on peut ecrire : 

checkTrace(O) ; 



wo 2005/073859 PCT/FR2004/003273 

20 

Apres compilation et conversion au format d' execution de la JCVM, on a un 
code objet de la forme : 

sconst_0 

invokestatic checkTrace 

5 Le procede de determination automatique de la valeur attendue de Tempreinte 
au moment du « invokestatic » pent s'appliquer au code objet de la JCVM et 
produire le code suivant : 

sspush 13991 

invokestatic checkTrace 

10 

Ce procede de determination automatique des valeurs d'empreinte peut etre 
combine a une analyse de programme qui effectue dans certaines cas un 
deroulage des boucles et recursions du programme. On peut alors calculer 
automatiquement des empreintes qui portent sur des variables du programme, 
15 comme dans Texemple ci-dessus ou « trace = h(trace, i) » figure k Tinterieur 
de la boucle d'indice « i ». 

L'empreinte peut etre calculee comme indique ci-dessus a partir de points 
d' observation donnes inserts explicitement dans le code du programme. 
20 L'empreinte peut aussi etre calculee automatiquement et implicitement par 
rinterprete d'une machine virtuelle. 

4 

En particulier, Tempreinte peut porter sur le code des instructions executees 
par la machine virtuelle. EUe permet ainsi de controler que Texecution 
25 successive des instructions du programme n'est pas perturbee. 

La boucle principale de Tinterprete d'une machine virtuelle a generalement la 
forme suivante : 
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while (1) { 

// Lecture du code de T instruction a Tadresse pc 
opcode = *pc++; 
switch (opcode) { 
5 case INSTR : 

// Semantique de T instruction « instr » 

• ■ • 

} 

> 

10 On peut instrumenter ce code ainsi : 

while (1) { 

opcode = *pc++; 
addTrace(opcode); 
switch (opcode) { 

15 

} 

} 

Pour le moment, on suppose que la variable « trace » associee a T operation 
20 «addTrace» est, a chaque appel de routine, sauvegardee dans le bloc 
deactivation de la routine appelante et reinitialisee a une valeur connue « To », 
et qu'elle est symetriquement restauree depuis le bloc d' activation de 
r appelant a chaque retour de routine. Ainsi, en un point quelconque du 
programme, la valeur de « trace » est « Tn = h(. . .h(h(To, ii), ia). . .5 in) »? qui est 
25 Tempreinte des codes operatoires «ii, ...,in» des instructions executees 
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depuis r entree dans la routine courante, en ignorant les instructions des 
methodes appelees. 



Cette mise a jour d'empreinte implicite pent 8tre prise en compte 
5 explicitement et automatiquement par le procede decrit ci-dessus de 
determination automatique des valeurs d'empreinte attendues. Des invariants 
du programme visible au niveau de la machine virtuelle peuvent en outre etre 
utilises pour la mise a jour d'empreinte : hauteur de la pile d'operande, 
presence de valeurs de certains types dans la pile d'operande (si la pile est 
10 typee ou si les donnees permettent d' identifier leur type) 



Le modele de calcul d'empreinte implicite par une machine virtuelle se 
transpose directement au cas d'lm microprocesseur executant du code natif. Le 
microprocesseur doit pour cela etre con9u pour tenir a jour I'empreinte pour 
15 chaque instruction executee. Dans cette approche, la variable « trace » devient 
un registre special du processeur, accede via des instructions de type « load » 
et « store » (pour sauver et restaurer la valeur de la trace k 1' entree et k la sortie 
des procedures), « addi » et « movi » (pour corriger et initialiser la valeur de la 
trace). 

20 D'un point de vue pratique, la prise d'empreinte doit etre realisee de maniere a 
ralentir au minimum le chemin critique du processeur. Ce pent Stre egalement 
un mode de fonctionnement debrayable du processeur, qui permet de 
n'effectuer les calculs d'empreinte que dans des sections critiques du code. 

Un debrayage dynamique de ce type peut egalement etre mis en oeuvre dans le 
25 cadre d'un calcul d'empreinte implicite par une machine virtuelle. 



Une autre possibilite pour accelerer le calcul d'empreinte est que le processeur 
dispose d'une instruction qui effectue 1' operation de mise a jour 
« trace = h(trace, x); » en hardware. Cette instruction machine peut etre 
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utilisee aussi bien dans la boucle d' interpretation d'une machine virtuelle que 
dans du code natif, ou elle pent 8tre inseree automatiquement par 
transformation du code machine, Le processeur pent comporter egalement des 
instructions d^diees pour effectuer les operations d'ajustements, d' affectations 
5 et de controle d'empreinte. 



De telles instructions specialisees peuvent egalement 8tre explicitement 
incluses dans le jeu d'instruction d'une machine virtuelle : au lieu d'operer 
explicitement sur une variable « trace » ou de faire des appels de routine du 
10 type « addTrace(N) »5 « setTrace(T) », « adjustTrace(N) » et 
« checkTrace(T) », ces operations peuvent etre realisees par des instructions 
dedi^es de la machine virtuelle. Le calcul d'empreinte n'est pas dans ce cas 
implicite : il est explicite et necessite une instrumentation (eventuellement 
automatique) du programme. 

15 

L'interet d'une telle approche est non seulement im gain en vitesse mais aussi 
en taille memoire. Ainsi, par exemple, au lieu des six octets que requidrent 
Tappel « checkTrace(42) » dans du code objet JCVM, seuls trois octets (un 
pour rinstruction et deux pour Targument entier court) seraient necessaires. 

20 Dans le cas ou Tempreinte est mise a jour automatiquement et implicitement 
par la machine d' execution (machine virtuelle ou processeur), plusieurs 
perfectionnements sont envisageables. 



Tout d'abord, pour diminuer le surcout en temps d' execution du a la prise 
25 d'empreinte, on pent envisager de ne pas modifier Tempreinte pour certaines 
classes d'instructions. Ceci pent s'effectuer a I'aide d'une table qui associe a 
tout code d' instruction un booleen qui indique si T instruction est a tracer. La 
boucle principale de Tinteiprete s'ecrit alors de la maniere suivante : 
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while (1) { 



opcode = *pc++; 

if (update__trace[opcode]) 

trace = li(trace, opcode); 
switch (opcode) { 



} 



} 



10 L'information des instructions a effectivement tracer (ici le tableau 
« updatejrace ») peut accompagner le programme lors de son chargement et 
de son execution sur la plate-forme d' execution. Cette information peut en 
outre varier suivant les programmes et meme suivant les differentes routines 
des diff6rents programmes. 

15 

On peut egalement coder cette information « en dur » dans Tinterprete pour 
les cas correspondants aux differents codes d' instruction. On a ainsi par 
exemple : 
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while (1) { 



opcode = *pc++; 
switch (opcode) { 
case INSTRl : // tracee 

trace = hCtrace, opcode); 



case INSTR2 : // pas tracee 



} 



10 > 



Pour detecter d'eventuelles perturbations sur la valeur des arguments 
imm6diats des instructions, on peut egalement les integrer dans le calcul de 
Tempreinte. Par exemple, dans le cas de la JCVM, pour Tinstruction 
15 «bspushn» (qui pousse la constante entiere «n» sur la pile d'operande), 
Tuiterprete peut effectuer « trace == h(h(trace, BSPUSH), n) » au lieu de 
simplement « trace = h(trace, BSPUSH) ». 



Pour conserver la possibilite de calculer statiquement les valeurs d'empreintes, 
20 ce schema ne peut etre applique qu'aux instructions dont les arguments 
imm^diats ne sont pas modifies au moment du chargement, a T edition de lien. 
Dans le cas contraire, il faut etre capable d'operer sur le programme apres 
edition de lien. C'est par exemple possible dans le cas ou le programme est 
inclus en memoire morte (ROM) dans un masque de carte a puce. 

25 

Pour rendre la valeur de I'empreinte encore plus sensible au flot de controle 
effectivement suivi a Tinterieur du code d'lme routine, les instructions de 
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branchement conditionnel (par exemple «ifzero» dans la JCVM) et de 
branchement multiple (par exemple « stableswitch » dans la JCVM) peuvent 
mettre a jovir la trace de maniere differente suivant que le branchement 
conditionnel est pris ou non, ou suivant T entree de la table de saut qui est 
5 selectionnee. Par exemple : 

switch (opcode) { 

case IFZERO: 

if (top_of_stack = 0) { 

trace = h(trace, BRANCH_TAKEN); 

10 pc+=pc[0]; 

} else { 

trace = h(trace, BRANCH_NOT_TAKEN); 
pc+= 1; 

} 

15 

On peut aussi voir ce perfectiomiement comme la prise en compte de la valeur 
connue de T expression « top_of_stack = 0 » dans chacune des branches de 
r instruction « ifzero », c'est-a-dire respectivement « true » et « false ». 



20 Dans ce qui a ete decrit jusqu'a present, Tempreinte est calculee routine par 
routine. II est inutile, et potentiellement couteux en temps d' execution, de 
mettre a jour la variable « trace » lors de T interpretation de routines qui ne 
vont jamais consulter la valeur de cette variable, c'est-a-dire qui ne 
contiennent pas d' operations de type « checkTrace ». L'information indiquant 

25 si une routine contient une operation « checkTrace » peut facilement etre 
determine par un simple examen du code de la routine. 
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L'interprete de la machine virtuelle peut alors 6tre modifie comme suit : 
while (1) { 

opcode = *pc++; 

if (method^flags & NEEDS_TRACE) 
5 trace = hCtrace, opcode); 

switch (opcode) { 
• • • 

} 

} 

10 

Dans le cas particulier de la JCVM, cette information peut par exemple etre 
calcul6e un fois pour toute (par exemple au chargement du programme) et 
enregistree sous forme d'un bit dans le champ « flags » de la structure 
« method_info ». 

15 

Jusqu'ici, on a considere I'empreinte d'execution comme locale a chaque 
methode : la variable « trace » est preserv^e a Tappel de routine, et sa valeur 
represente une empreinte des points d' observation de Texecution a Tinterieur 
de la routine courante, en excluant les routines appelees. La variable « trace » 
20 peut 6tre rendue globale, et done contenir une empreinte de toutes les 
instructions executees, y compris a travers des appels de routines, depuis des 
points d' entree connus (par exemple, les methodes « process » et « install » 
d'une applet « Java Card »), ou « trace » a ete initialisee a des valeurs 
connues. 

25 

Les motivations sont doubles : d'une part la possibilite de verifier en une seule 
operation «checkTrace» I'absence de perturbations dans Texecution 
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complete du programme, et non pas juste dans Texecution de la routine ou se 
trouve le « checkTrace » ; et d' autre part, dans le cas ou Tempreinte est prise 
implicitement par la machine d' execution, la simplification de cette machine 
(plus besoin de sauvegarder et de restaurer « trace » a chaque appel). 

5 La principale difficulte de cette approche est le calcul statique des valeurs de 
Tempreinte en tout point du programme. Ce calcul reste possible, mais exige 
ou bien une analyse du programme complet (interprocedurale), ou bien 
Tetablissement d'invariants sur les valeurs de Tempreinte au debut et a la fin 
de chaque routine. 

10 

Dans r approche par analyse globale, on suppose connaitre, au moment de 
r analyse statique, le code de toutes les routines pouvant etre appelees 
directement ou indirectement a partir des points d' entree du programme, y 
compris les routines appartenant a d'autres programmes, en particulier celles 
15 de librairies. 



Sous cette hypothese, le procede de determination statique de Tempreinte 
d6crit ci-dessus s'etend comme suit : au lieu d' analyser et de transformer 
chaque routine individuellement, on les transforme toutes en meme temps, en 
20 traitant les instructions d' appel de routines (« invoke », « call », etc.) comme 
des branchements inconditionnels a la premiere instruction de la routine 
appelee, et les instructions de retour d' appel (« return », etc.) comme des 
branchements vers les instructions suivant immediatement T appel 
correspondant. 

25 

En d'autres termes, on travaille non plus sur le graphe de flot de controle de la 
routine, mais sur le graphe de flot de controle interprocedural, contenant des 
arcs suppl6mentaires correspondant aux instructions d' appel et de retour de 
routine. On notera que pour les instructions qui determinent dynamiquement la 
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routine a appeler effectivement (comme par exemple Tappel de methode 
virtuelle ou de methode d' interface), on ajoute des arcs de et vers toutes les 
routines en lesquelles Tappel pent se resoudre dynamiquement. Par exemple, 
dans la JVM, une approximation simple de T ensemble des methodes cibles de 
5 « invokevirtual Cm », est T ensemble des m6thodes « m » definies dans la 
classe « C » ou Tune de ses sous-classes. (On peut obtenir de meilleures 
approximations de cet ensemble k Taide d' analyses statiques de flot de 
controle.) 



10 Le procede decrit ci-dessus dans le cas d'un routine, applique a ce graphe 
interprocedural, va inserer les ajustements d'empreintes necessaires pour que 
la valeur de I'empreinte soit la meme a tous les sites d'appel d'une m6me 
routine, et a la fin de toutes les routines susceptibles d'etre appelees depuis le 
meme site d'appel. 

15 

Le probleme de I'approche globale ci-dessus fest_ que Thypothese selon 
laquelle on connait le code de toutes les routines est parfois trop forte : on 
connait le code des methodes du package en cours de transformation, mais pas 
forcement celui des routines de librairies ou partage avec d'autres 
20 programmes. 



Une premiere solution est de preserver la valeur de I'empreinte a travers les 
appels a des routines qui ne font pas partie du programme, par exemple en 
sauvant et restaurant la variable « trace » autour de ces appels. 

25 

Une autre solution, qui permet egalement de faire 1' economic de 1' analyse de 
flot interprocedurale, consiste a etablir le « contrat » suivant entre toutes les 
routines : pour chaque routine de nom «r», si la valeur de I'empreinte est 
« E(r) » a r entree dans la routine, alors la valeur de I'empreinte est « S(r) » a 
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la sortie de la routine, Ici, « E » et « S » sont des fonctions associant des 
valeurs d'empreinte arbitraires a des noms de routines, par exemple calculees 
par hachage cryptographique. La signature de la routine (type de ses 
arguments et de la valeur de retour) peut aussi etre associee au nom, 
5 notamment si elle permet de distinguer des routines sans rapport entre elles. 

Le « contrat » ci-dessus est simple k assurer : avant chaque instruction d'appel 
a une routine « r », on insere un ajustement de Tempreinte pour Tamener a la 
valeur « E(r) » ; et pour chaque instruction de retour d'appel, on insere de 
meme un ajustement de Tempreinte pour Tamener a la valeur « S(r) ». 

10 

Ce principe s'etend au cas de m^thodes d6termin6es dynamiquement au 
moment de Tappel. Par exemple, dans le cas de « Java » ou de « Java Card », 
on peut employer des paires « (m, s) » ou « m » est ira nom de methode et 
« s » une signature de methode. Des hachages de cette paire permettent de 
15 definir « E(m,s) » et « S(m,s) ». On peut noter que si une methode virtuelle en 
redefinit une autre, ces deux methodes ont meme nom et m6me signature, 
done memes valeurs « E » et « S ». Le « contrat » sur les empreintes a Tappel 
et au retour de methodes s' applique ainsi de meme maniere. 



20 Dans la mesure ou seuls sont pris en compte les noms des routines (et 
eventuellement leur signature), la determination des valeurs d'empreinte peut 
s'effectuer routine par routine, sans connaitre I'integralite du programme. La 
sortie prematuree d'une routine via une exception non rattrapee ne pose pas de 
probldme supplementaire, sous Thypoth^se que la machine virtuelle 

25 (implicitement) ou le gestionnaire d' exception (explicitement) reinitialise 
toujours Tempreinte a ime valeur constante connue lorsqu'xme exception est 
declenchee. 
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Au lieu de demander au programmeur d'indiquer explicitement dans le source 
les endroits oti une verification de Tempreinte doit etre effectuee (par exemple 
avec des appels explicites a « checkTraceQ »), ces verifications peuvent aussi 
6tre inserees automatiquement par un outil de transformation du code, 

5 

Par exemple, dans le cas de la JC VM, on peut effectuer un controle : 

• avant chaque instruction qui ecrit en memoire persistante (EEPROM) : 
ecriture dans un champ de classe (« putstatic ») ou de d' instance 
(« putfield »), ecriture dans im tableau (« x-astore »), 

10 • au debut et a la fin de chaque transaction, 

• avant Tappel de certaines methodes de librairie, etc. 

Cela permet notamment de mettre en place une politique de controle 
d'integrite d' execution qui considere que le programme peut executer 
15 n'importe quelles operations, eventuellement perturbees, tant qu'il ne cherche 
pas a modifier la valeur des donnees persistantes et a faire des entrees-sorties. 

La strategic d' insertion automatique des verifications d'empreintes est facile a 
changer, puisqu'elle affecte uniquement la phase de transformation du code. 
20 Elle resulte en pratique d'un compromis a trouver entre la fi-equence des 
verifications et T augmentation de la taille du code et du temps d' execution dus 
aux operations « checkTrace ». 

Plutot que de modifier explicitement le programme par insertion d' instructions 
25 dans le code (par exemple pour appeler des routines du type « addTrace », 
« checkTrace », « adjustTrace » et « setTrace »), les donnees de prise et de 
controle d'empreinte peuvent etre stockees dans des tables independantes au 
code executable du programme. Ces donnees peuvent comprendre les points 
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de programme ou une operation d'empreinte est effectuee ainsi que les valeurs 
associees (les arguments de ces operations). C'est la machine d' execution (par 
exemple une machine virtuelle) qui se charge alors d'effectuer ces operations 
lorsque le point de programme courant passe par les points de programme 
5 memorises dans les tables. 



Plutot que r argument effectif d'une operation d'empreinte, les tables peuvent 
aussi stocker des valeurs qui indiquent quelles donnees dynamiques prendre en 
compte dans Top^ration, Par exemple, une entree complexe correspondant a 
10 « addTrace » peut indiquer de mettre a jour Tempreinte avec la valeur 
courante d'une variable ou d'un registre de la machine (parce que sa valeur est 
connu statiquement). 



Un avantage de cette approche est de reduire Tencombrement memoire des 
15 informations de calculs et de controle d'empreinte. En revanche, elle peut 6tre 
couteuse en temps d' execution du fait des parcours de table. En cas de 
probldme de performance, on peut employer une approche mixte : certaines 
operations sont calculees automatiquement par la machine d' execution ; 
d'autres operations sont inserees explicitement dans le code du programme ; 
20 d'autres operations encore sont stockees dans des tables. Par exemple, 
r operation « addTrace » peut etre calculee par une machine virtuelle ; les 
operations « checkTrace » et « setTrace » peuvent etre exprimees par des 
appels de routine explicites ; et « adjustTrace » peut 6tre implement^e par une 
recherche en table. De plus, pour des raisons d'efficacite, la recherche en table 
25 pour « adjustTrace » peut n'etre effectuee que dans le cas ou un branchement 
est pris (en supposant les ajustements effectifs pratiques xmiquement dans ces 
cas-la). 
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Dans la mesure ou les operations de calculs et de controle d'empreinte ne sont 
pas standardis^es, un programme instmmente comme decrit ci-dessus pour le 
contrdle d'integrite d' execution peut ne pas fonctionner sur les plates-formes 
d' execution qui ne sont pas adaptees. 

5 

Dans le cas ou le code fait explicitement apparaitre des appels de routine 
sur les empreintes (du type « addTrace », « checkTrace », « adjustTrace » et 
« setTrace »), le programme peut etre accompagne d'une librairie qui 
implemente ces routines. II sera alors portable sur toutes les plates-formes 
10 d' execution. Toutefois, si la plate-forme dispose d'une implementation plus 
efficace, elle peut la substituer a celle foumie avec le programme 



Dans le cas d'un codage des prises et controles d' empreintes dans des tables, 
le programme est davantage portable. Par exemple, dans le cas de d'une 
15 JCVMj les tables peuvent etre foumies sous forme de composants 
personnalises supplementaires : soit la machine les reconnait et les exploite ; 
soit elle ne les reconnait pas et les ignore (et dans ce cas ne pratique pas de 
verification d'integrite d' execution). 
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1. Precede de controle d'integrite d'execution d'un programme par 
verification d'empreintes de traces d' execution, caracterise eii ce qu'il 
5 comprend : 

- la mise ^ jour d'une empreinte representative du chemin d' execution 
et/ou des donnees manipulees lors de 1' execution du programme, 

- la comparaison de ladite empreinte (valeur courante, calculee 
dynamiquement) a une valeur attendue (fixee statiquement, 6gale la 

10 valeur que doit avoir T empreinte si 1' execution du programme n'est 

pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier dans le cas ou Tempreinte 
courante difffere de la valeur attendue. 



15 2. Procede selon la revendication 1, caracterise en ce que le traitement 
particulier du programme dans le cas ou T empreinte courante differe de la 
valeur attendue consiste a securiser certaines donnees et/ou a avertir 
Tutilisateur du dysfonctionnement par un signal sonore ou visuel et/ou a 
interrompre, definitivement ou non, 1' execution dudit programme. 

20 

3. Procede selon la revendication 1, caracterise en ce que ladite empreinte ne 
porte que sur des fragments de code critiques du programme et/ou dans des 
etats du programme juges critiques. 



25 4. Procede selon la revendication 1, caracterise en ce que ladite empreinte est 
calculee incrementalement le long du chemin d' execution du programme 
par composition successive d'une fonction dont un argument est la valeur 
courante de T empreinte et un autre argument est une donnee d' observation 
specifique au point et au moment de mise a jour de T empreinte (etat du 
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programme et/ou du point d' execution du programme et/ou des donnees 
manipnl^es). 



5. Procede selon la revendication 4, caracterise en ce que ladite fonction 
5 consiste en Tune des fonctions suivantes : somme de controle 
(« checksum »), congruence lineaire, controle de redondance cy clique 
(CRC), hachage cryptographique (« digest »), ou combinaison des 
operations suivantes : addition, soustraction, « ou » logique exclusif 
(« xor ») avec ime constante ou avec ladite donnee d' observation ; rotation 
10 d'un nombre constant de bits ; multiplication par une constante impaire. 



6. Procede selon la revendication 1, caracterise en ce que Tempreinte est 
ajustee le long des chemins d' execution avant d'atteindre certains points de 
convergence du flot de controle de manidre a rendre egales les empreintes 
1 5 des chemins convergents . 



7. Procede selon la revendication 6, caracterise en ce que Toperation 
d'ajustement consiste en une combinaison des fonctions suivantes : 
affectation a ime valeur constante, addition avec une constante, « ou » 
20 logique exclusif (« xor ») avec une valeur constante. 



8. Procede selon la revendication 1, caracterise en ce que, en certains points 
du programme, Fempreinte est affectee a une certaine valeur plutot que 
d^duite de la valeur d'empreinte precedents 

25 

9. Procede selon la revendication 8, caracterise en ce que lesdits points de 
programme sont ceux ou conflue un nombre de branches d' execution 
superieur a un certain seuil et/ou ceux qui sont les points d' entree de 
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subroutines et/ou de gestionnaires d' exception, et en ce que ladite valeur 
affectee est une valeur donn6e et/ou une valeur quelconque determinee par 
tirage aleatoire et/ou une expression de programme determinee par une 
analyse prealable comme invariante au point de programme considere. 

5 

lO.Proc^de selon la revendication 1, caracterise en ce que la valeur de 
Tempreinte est comparee a la valeur attendue en des points du programme 
determines par leur caracteristique particuliere dans le graphe de flot de 
controle dudit programme et/ou par la nature des operations effectu6es 
10 auxdits points de programme. 



ll.Procede selon la revendication 10, caracterise en ce que lesdits points de 
programme sont situes apres chaque branchement et/ou avant chaque point 
de jointure du flot de controle et/ou avant chaque operation qui ecrit en 
15 memoire persistante et/ou avant certaines operations cryptographiques 
et/ou avant I'appel de certaines routines de librairie et/ou apres I'appel de 
certaines routines de librairie. 



12.Proced6 selon Tune des revendications 1 a 1 1, caracterise en ce que la prise 
20 d'empreinte (calcul et/ou mise a jour et/ou ajustement et/ou affectation) 
et/ou le controle d'empreinte sont realises : 

- explicitement par une instrumentation du code du programme, et/ou 

- explicitement par la machine d' execution (machine virtuelle et/ou 
processeur de la plate-forme d' execution), sur la base 

25 d' informations complementaires au programme qui indiquent a 

ladite machine d' execution en quels points de programme et/ou avec 
quelles valeurs (y compris des valeurs resultant d' operations 
complexes) effectuer des operations de prise et/ou de controle 
d'empreinte, et/ou 
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- implicitement par la machine d' execution (machine virtuelle et/ou 
processeur de la plate-foraie d' execution), sur la base d'une 
observation particuliere des instructions executees. 



5 13.Procede selon la revendication 12, caracterise en ce que ladite 
instrumentation du code du programme est basee sur la manipulation 
explicite d'une variable ou d'un registre representant Tempreinte et/ou sxir 
Tappel a des routines specialisees et/ou sur Temploi d' instructions 
specialisees de la machine d' execution. 

10 

14.Procede selon la revendication 12, caracterise en ce que lesdites 
informations complementaires sont codecs dans des tables qui associent 
des points de programmes a un code definissant F operation a realiser et qui 
ne sont consultees par la machine d' execution que lors de T execution 
15 d' instructions particulieres. 



15. Procede selon la revendication 14, caracterise en ce que lesdites 
instructions particulieres sont des branchements et/ou des ecritures en 
memoire persistante et/ou des appels a certaines routines et/ou certaines 

20 operations cryptographiques. 

16. Procede selon la revendication 1, caracterise en ce que les valeurs 
attendues de Tempreinte et des ajustements d'empreinte en des points 
donnes du programme sont determinees par une analyse statique du code 

25 du programme (source ou objet) qui peut simuler le d^roulage de certaines 
boucles et recursions et qui peut modifier le code du programme pour 
rendre les valeurs d'empreinte previsibles et/ou pour les controler. 
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17. Precede selon I'une des revendications 4 a 16, caracterise en ce que sont 
foumies a ladite analyse des infoimations concemant la mise a jour 
d'empreinte (points de programme et nature des observations de 
Texecution en ce point de programme) et/ou Tajustement d'empreinte 
5 (points de programme oti I'empreinte doit 6tre ajustee a une certaine 
valeur) et/ou T affectation d'empreinte (points de programme ou 
I'empreinte doit etre forcee a xme valeur) et/ou le controle d'empreinte 
(points de programme oil I'empreinte doit dtre contr616e), ces 
informations : 

10 - etant determinees automatiquement conformement au procede selon 

Tune des revendications 6 a 1 1, et/ou 

- etant donnees sous forme de directives consistant en des instructions 
placees dans le code du progranmie et operant sur Tempreinte (telles 
que des appels de routine, prenant ou non en argument un entier 
15 quelconque) et/ou etant foumies sous forme de tables complementaires 

au programme, 

~ et pouvant etre completees et/ou modifiees selon les valeurs calculees 
par ladite analyse. 



20 18. Procede selon la revendication 17, caracterise en ce que, pour chaque 
routine du programme, les valeurs d'empreinte attendues sont determinees 
par la sequence operatoire suivante : 

• Initialisation de T ensemble des points de programme a explorer au 
singleton constitue de la premiere instruction de la routine. 

25 • Memorisation au point d' entree de la routine d'une valeur d'empreinte 
egale a la valeur initiale donnee de I'empreinte. 

• Tant que ledit ensemble des points de programme a explorer n'est pas 
vide : 



wo 2005/073859 PCT/FR2004/003273 

39 

- Extraction d'un point de programme (le point d'origine) dudit ensemble 
des points de programme a explorer. 

- Pour chacun des points de programme resultants possibles apres 
execution de T instruction (les points cibles) : 

5 * Si le point cible comporte une affectation d'empreinte et si ce point 

cible n'a pas encore ete explore, memorisation au point cible de la 
valeur d'empreinte definie par T affectation. 

* Si le point cible ne comporte pas d' affectation d'empreinte et si ce 
point cible a deja ete explore, insertion entre T instruction au point 

10 d'origine et Tinstruction au point cible d'un ajustement d'empreinte 

qui envoie la valeur de Tempreinte au point d'origine sur la valeur 
de Tempreinte memorisee au point cible. 

* Si le point cible ne comporte pas d' affectation d'empreinte et si ce 
point cible n'a pas encore ete explore, memorisation au point cible 

15 de la valeur de Tempreinte au point d'origine, modifiee par une 

mise a jour d'empreinte s'il y en a une entre le point d'origine et le 
point cible. 

* Si le point cible n'a pas encore ete explore, ajout dudit point cible 
dans ledit ensemble des points de programme a explorer. 

20 

19.Procede selon I'une des revendications 12 a 18, caracterise en ce que d'une 
part I'empreinte porte sur 1' execution complete du programme (y compris 
avec appels de routines) a partir de ses points d' entree et d' autre part le 
procede selon la revendication 17 est applique a un ensemble de routines 
25 en traitant les instructions d'appel statique de routine comme des 
branchements inconditionnels a la premiere instruction de la routine 
appelee, les instructions d'appel dynamique de routine comme des 
branchements conditionnels k lei premiere instruction de la routine appelee 
correspondante, et les instructions de retour d'appel comme des 
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branchements vers les instructions suivant immediatement Tappel 
correspondant. 

20. Precede selon la revendication 12, caracterise en ce que le programme 
5 et/ou la machine d' execution sont instrumentes pour que Tempreinte soit 
sauvegardee a Tappel de certaines routines (telles que celles qui ne font pas 
partie du programme ou qui ne sont pas analysables) et restauree au retour 
de Tappel. 



10 21.Procede selon la revendication 12, caracterise en ce que le programme 
et/ou la machine d' execution sont instrumentes pour que I'empreinte soit 
ajustee a Tappel et au retour de certaines routines (y compris dans le cas de 
routines determinees dynamiquement au moment de Tappel) de maniere a 
etre egale : 

15 - a r entree de la routine appel6e : k une valeur qui depend du nom 

et/ou de la signature de la routine appelee (telle qu'ime valeur 
obtenue par hachage crj^tographique du nom et/ou de la signature) ; 

- apr^s retour dans la routine appelante : a une valeur qui depend de la 
meme maniere du nom et/ou de la signature de la routine appelee, 
20 chaque gestionnaire d' exception conceme par Tappel de routine 

(c'est-a-dire pouvant 6tre atteint lors de la levee d'une exception 
dans la routine appelee) devant affecter Tempreinte a une valeur 
determinee. 



25 22.Procede selon Tune des revendications 3 et 12, caracterise en ce que, dans 
le cas ou I'empreinte est mise a jour implicitement par une machine 
d' execution : 

- la prise d'empreinte peut etre temporairement suspendue pour eviter 
des calculs inutiles lors de T execution de firagments de code non 
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critiques du programme et/ou dans des etats du programme juges non 
critiques et/ou lors de T execution de certaines routines n'effectuant pas 
de controle d'empreinte ; 

- la prise d'empreinte, lorsqu'elle n'est pas suspendue, porte sur chaque 
5 instruction executee, 

* y compris certains de ses arguments immediats et/ou certains des 
invariants du programme pour cette instruction (tels que la hauteur 
de la pile d'operande ou la presence de valeurs de certains types 
dans la pile d'operande) et/ou les choix de branches effectues dans 

10 le cas ou T instruction est un branchement, 

* mais a la condition que I'instruction ex6cut6e appartienne k une 
classe donnee des instructions a observer, ladite classe etant fixe 
pour la machine d' execution ou bien donnee par une table associant 
a tout code d' instruction un booleen indiquant si I'instruction est a 

15 observer, et ladite table etant specifique a differentes routines et/ou 

diff6rents programmes. 



23.Procede selon la revendication 12, caracterise en ce que : 

- certaines operations sur Tempreinte (telles que T affectation et le 
20 controle d'empreinte) sont inserees explicitement dans le code du 

programme ; 

- certaines operations sur Tempreinte (telles que Tajustement 
d'empreinte) sont effectuees explicitement par la machine 
d' execution en fonction d' informations complementaires au 

25 programme ; 

- certaines operations sur Tempreinte (telles que la mise a jour 
d'empreinte) sont effectuees implicitement par la machine 
d' execution. 
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24, Precede selon la revendication 12, caracterise en ce que : 

- dans le cas ou des operations de prise et/ou de controle d'empreinte 
sont effectuees par des appels de routine, le programme est 
accompagne d'une librairie qui implemente ces routines, ladite 

5 librairie etant pouvant etre substituee par une implementation 

particuli^re lors du chargement sur une plate-forme d' execution ; 

- dans le cas ou les operations de prise et de controle d'empreinte sont 
exprimees par des informations complementaires au programme et 
oil la plate-forme d'execution ne salt pas et/ou ne peut pas et/ou ne 

10 veut pas exploiter ces informations, lesdites informations sont 

ignorees pour permettre Texecution sans le controle d'integrite. 



25.Procede selon Tune des revendications 12 et20, caract6ris6 en ce que la 
machine d' execution du programme dispose d' instructions specialisees 

15 pour le calcul d'empreinte et/ou la mise a jour d'empreinte et/ou 
I'ajustement d'empreinte et/ou I'affectation d'empreinte et/ou le controle 
d'empreinte et/ou la sauvegarde d'empreinte a I'appel d'une routine et la 
restauration d'empreinte au retour d'une routine, ces instructions 
apparaissant explicitement dans le code du programme et/ou etaut utilisees 

20 pour mettre en oeuvre la machine d' execution. 



26.Systeme d' execution permettant le controle d'integrite d' execution, 
caracteris6 en ce que ledit systeme inclut un microprocesseur qui dispose 
d' instructions specialisees pour le calcul d'empreinte et/ou la mise a jour 
25 d'empreinte et/ou I'ajustement d'empreinte et/ou I'affectation d'empreinte 
et/ou le controle d'empreinte et/ou la sauvegarde d'empreinte a Tappel 
d'xme routine et la restauration d'empreinte au retour d'une routine, 
conformement au procede selon I'une des revendications 1 ^ 25. 



